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Abstract 


This  document  describes  the  information  sharing  requirements  and  the 
approaches  used  to  fulfill  those  requirements  in  the  development  of 
standardized  data  constructs  for  STEP  (Standard  for  the  Exchange  of  Product 
Model  Data).  It  also  describes  the  information  architecture  that  conceptually 
organizes  the  standardized  constructs  and  information  systems  architectures  in 
which  these  constructs  can  be  used. 


Keywords:  application  interpretation,  product  data,  product  data  architecture, 
product  data  integration,  product  data  modelling,  product  data 
specification,  product  information  sharing,  resource  integration 
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1 Introduction 


STEPi  is  a standard  that  provides  the  basis  for  information  sharing  using 
computer  interpretable  product  model  data.  Unambiguous  information  sharing 
is  facilitated  by  STEP  through  the  use  of  standardized  constructs  (data  modelling 
structures  that  formally  define  information). 

This  paper  contains  a description  of  information  sharing  requirements  for  STEP 
in  section  2.  Section  3 contains  a description  of  the  information  sharing 
environment  in  which  implementations  of  STEP  will  need  to  operate.  Section  4 
contains  a discussion  of  the  information  architecture  used  to  conceptually 
organize  the  constructs  developed  by  STEP.  Section  5 contains  a description  of 
information  systems  architectures  that  can  be  used  to  implement  the 
standardized  constructs  of  STEP. 


1.1  Scope 


The  material  presented  in  this  document  is  responsive  to  requirements  placed 
on  the  major  design  principles  for  the  development  of  STEP.  This  includes 
functional,  compatibility,  conceptual,  and  developmental  requirements  [1,2]. 
Functional  requirements  include  data  exchange,  archiving,  sharing,  and  access 
completeness  as  well  as  extensibility  of  the  standard.  Compatibility  requirements 
include  upward  compatibility  in  a phased  release  environment.  Conceptual 
requirements  include  the  use  of  a minimal  set  of  non-redundant  concepts.  The 
development  approach  requirements  include  the  methods  used  in  the 
integration  of  product  data  resources  and  the  interpretation  of  the  integrated 
resources  in  particular  application  contexts. 


1 STEP  (Standard  for  the  Exchange  of  Product  Model  Data)  is  the  name  used  to  identify 
ISO  (International  Organization  for  Standardization)  10303  developed  under  Technical 
Committee  184  / Sub-Committee  4. 


1.2  Definitions 


Application:  Any  enterprise  process  or  function  that  generates  or  uses  data. 

Application  Activity  Model  (AAM):  A representation  of  the  activities  which  use 
product  data  in  a specific  application  context.  It  is  used  to  establish  an  under- 
standing and  agreement  concerning  the  technical  boundary  of  the  application 
and  for  uses  of  the  data  (i.e.,  a clear  definition  of  scope). 

Application  Interpretation:  The  development  of  a conceptual  schema,  satisfying 
a set  of  user  requirements,  from  integrated  resource  constructs. 

Application  Interpreted  Construct  (AIC):  A logical  grouping  of  concepts  that  is 
shared  by  two  or  more  application  interpreted  models. 

Application  Interpreted  Model  (AIM):  A schema  that  specifies  the  STEP  product 
data  constructs  used  for  the  sharing  of  information  in  the  application  context 
specified  by  the  application  protocol  in  which  it  appears. 

Application  Protocol  (AP):  Specification  of  STEP  constructs  used  for  the  sharing 
of  information  in  a particular  product  data  application  context.  It  enumerates 
the  conformance  requirements  and  test  purposes  used  in  the  evaluation  of  an 
implementation. 

Application  Reference  Model  (ARM):  A schema  that  describes  the  information 
requirements  and  constraints  for  a product  data  application.  The  schema  is  a 
consensus  user  view  that  employs  application-specific  terminology  and  rules 
familiar  to  experts  from  the  application  domain. 

Conceptual  Schema:  A schema  representing  the  canonical  data  view  in  an 
information  system.  A conceptual  schema  supports  the  requirements  of 
multiple  user-application  views  (i.e.,  external  schemas).  It  is  independent  of 
implementation  views  (i.e.,  internal  schemas). 

Construct:  A data  modelling  structure  that  represents  a semantic  abstraction  of 
an  idea  (a  logical  grouping  of  fact  types). 

Context:  A set  of  related  conditions  that  elucidates  a particular  meaning. 
Conditions  in  STEP  include  those  which  limit  the  relevant  products  or 
descriptions  of  products  for  which  information  is  shared  (e.g.,  mechanical 
products  described  from  the  point  of  view  of  design). 
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Data:  One  or  more  facts  used  for  reasoning,  communication,  or  calculation. 

Draft  Resource  Model:  A schema  that  describes  the  information  requirements 
and  constraints  for  a product  data  subject  areas  (e.g.,  geometry).  The  schema  is  a 
consensus  subject  area  view  that  employs  specific  terminology  and  rules  familiar 
to  experts  from  that  subject  area. 

External  Schema:  A schema  representing  a user-application  view  in  an 
information  system.  An  external  schema  has  a specified  mapping  to  a 
conceptual  schema  in  an  information  system  architecture. 

Fact:  A particular  occurrence  of  a proposition  considered  to  be  true  (e.g.,  a value 
of  an  attribute  for  an  instance  of  an  entity  or  a relationship  between  instances  of 
entities). 

Fact  Type:  A data  modelling  structure  that  represents  a formal  proposition  (e.g., 
an  attribute  of  an  entity  or  a relationship  between  entities).  - 

Information:  An  organized  collection  of  related  data  in  an  established  context  for 
communication. 

Information  Model:  A collection  of  related  constructs,  described  in  a formal  data 
modelling  language,  that  capture  the  semantics  of  a chosen  domain  of  discourse. 

Integrated  Resources:  A collection  of  schemas  with  controlled  interschema 
references  that  provides  a unification  of  constructs  from  multiple  product  data 
subject  areas  and  is  consistent  with  an  established  integration  architecture. 

Internal  Schema:  A schema  representing  an  implementation  view  of  an 
information  management  system.  An  internal  schema  has  a specified  mapping 
to  a conceptual  schema  in  an  information  system  architecture. 

Resource:  A construct  which  is  free  of  a specific  product  data  application  context. 
Its  context  is  that  of  a specified  product  data  subject  area.  It  is  available  for 
interpretation  into  a product  data  application  context. 

Resource  Integration:  The  unification  of  product  data  constructs  using  an 
explicit  architecture  that  serve  as  a resource  for  the  development  of  information 
sharing  standards  in  specific  application  contexts. 

Schema:  A formal  data  modelling  structure  used  to  define  a construct. 
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2 Information  Sharing  Requirements 


STEP  contributes  to  the  establishment  of  product  information  sharing  among 
computer  systems  by  specifying  sufficient  semantic  content  for  data  to  be 
interpretable  directly  by  application  programs.  The  principal  requirement  is  that 
STEP  be  general  enough  to  handle  product  data  for  a wide  variety  of  applications 
and  specific  enough  to  meet  the  needs  of  particular  users. 

The  development  of  STEP  constructs  involves  two  fundamental  aspects.  The 
first  aspect  emphasizes  constructs  that  are  of  potential  use  to  any  product  data 
application  (i.e.,  an  emphasis  on  requirements  from  product  data  subject  areas). 
The  second  aspect  emphasizes  product  data  constructs  that  are  used  for  particular 
purposes  (i.e.,  an  emphasis  on  specific  product  data  application  requirements). 
STEP  provides  data  specifications  that  support  both  aspects. 

STEP  Information  Sharing  Requirements 

• Establish  standard  data  specifications  for  information  sharing 
among  applications  involving  a wide  variety  of  product  types  over 
the  entire  life  cycle  of  products. 

- Accommodate  all  data  used  for  product  description. 

- Accommodate  all  product  life  cycle  perspectives  that  use  product  data. 

- Accommodate  multiple  ways  of  using  data. 

• Establish  standard  data  specifications  for  information  sharing  among 
specific  applications  that  satisfies  the  needs  of  industry  and  commerce. 

- Share  product  data  precisely  and  unambiguously. 

- Share  product  data  among  specific  applications. 

- Share  product  data  without  restricting  the  way  an  enterprise  uses  data 
so  industry  can  adopt  improved  processes. 

The  fundamental  prerequisite  for  STEP  to  be  successful  is  that  it  satisfies  these 
requirements.  To  this  end,  integrated  resource  constructs  are  developed  for 
product  data  subject  areas  from  which  application  interpreted  constructs  are 
developed  to  meet  product  data  application  requirements.  The  STEP 
development  methods  and  architecture  support  both  precision  of  the 
information  shared  within  product  data  application  contexts  and  flexibility  in 
sharing  information  among  product  data  applications. 
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3 Information  Sharing  Environment 


Information  sharing  using  STEP  must  accommodate  heterogeneous,  distributed, 
and  autonomous  information  system  environments.  It  is  heterogeneous  in  that 
it  involves  sharing  among  dissimilar  information  systems  (e.g.,  computer-aided 
design  systems).  It  is  distributed  in  the  sense  that  various  pieces  of  the  total 
information  available  may  exist  on  a number  of  systems  at  different  locations 
with  possible  replication  of  data.  It  is  autonomous  in  that  each  of  the 
information  systems  is  typically  designed  to  function  independently. 

Two  principal  approaches  to  the  integration  of  information  systems  in  this  type 
of  complex  environment  have  been  proposed  [3,4,5].  The  first  is  a global 
approach  where  a single  conceptual  view  is  developed  through  an  integration  of 
all  local  information  systems.  The  second  approach  is  a federated  approach 
where  classes  of  users  develop  consensus  federated  views  (conceptual  in  nature) 
which  are  then  supported  by  local  systems.  Global  and  federated  systems  are 
equivalent  when  a federated  system  contains  only  a single  federated  view.  STEP 
has  been  developed  to  provide  constructs  useful  to  each  of  these  information 
system  architectures. 

STEP  Development  Approach 

The  STEP  project  cannot  identify  and  integrate  all  information  systems  that  deal 
with  product  model  data.  This  would  be  equivalent  to  knowing  the  conceptual 
view  of  every  information  system  in  every  enterprise  that  will  ever  use  STEP. 
The  STEP  project  has  adopted  an  approach  that  uses  knowledge  of  product  data 
subject  area  requirements  to  specify  a compatible  set  of  integrated  constructs  that 
spans  the  range  of  current  and  anticipated  systems.  Although  not  a single  global 
schema,  these  constructs  define  a standard  integrated  information  structure  that 
serves  as  a resource  for  development  within  STEP.  These  constructs  establish  a 
product  data  context  and  are  called  the  STEP  Integrated  Resources  (IRs). 

STEP  also  contains  the  specification  of  constructs  for  information  sharing  in 
specific  application  contexts.  Classes  of  users  that  cross  national  and  enterprise 
boundaries  define  consensus  product  data  application  requirements.  The 
Integrated  Resources  are  interpreted  for  information  sharing  purposes  within  a 
specific  context  (STEP  Application  Protocols,  APs).  Application  Interpreted 
Constructs  (AICs)  are  established  to  serve  as  standard  information  elements  that 
facilitate  sharing  among  multiple  APs. 


5 


4 Information  Modelling 


The  STEP  project  has  chosen  conceptual  modelling  as  its  principal  technical 
approach  to  specify  standardized  constructs  that  facilitate  information  sharing. 
The  development  of  standardized  constructs  includes  a formal  language  for  the 
specification  of  constructs  and  an  explicit  data  architecture  for  product  data 
applications. 


4.1  Information  Model  Specification 


The  formal  language  for  conceptual  modelling  and  data  specification  in  STEP  is 
EXPRESS.  The  EXPRESS  language  [6]  provides  the  syntactic  mechanism  for  the 
specification  of  data  elements  and  structures  in  both  human-readable  and 
computer-processable  form.  The  particular  use  of  EXPRESS  by  STEP  [7,8,9] 
provides  a pragmatic  mechanism  for  the  specification  of  constructs  to  satisfy 
STEP  requirements.  Integration  and  interpretation  of  the  constructs  within  the 
IRs  and  APs  that  satisfy  the  information  architecture  of  STEP  [10]  provide  the 
semantic  mechanisms  by  which  the  standard  is  specified. 

Integration  and  interpretation  are  the  development  methods  used  by  STEP  to 
provide  semantically  precise  information  models.  The  methods  are  responsive 
to  the  dual  requirements  for  generality  (i.e.,  constructs  that  are  useful  for  a wide 
variety  of  product  data  applications)  and  specificity  (i.e.,  constructs  that  are  useful 
for  particular  product  data  applications).  Integration  develops  a unified 
canonical  data  structure  with  associated  constraints  from  models  developed  by 
experts  in  product  data  subject  areas.  Interpretation  derives  an  application 
specific  specification  from  that  data  structure  adding  necessary  constraints  based 
on  explicitly  defined  product  data  requirements  of  industry  and  commerce. 

The  methods  that  are  used  to  specify  information  models  in  STEP,  therefore 
reflect  a specific  information  architecture. 


4.2  Information  Architecture 


The  information  architecture  includes  Integrated  Resources  (IRs)  and 
Application  Protocols  (APs).  The  IRs  establish  an  abstract  framework  containing 
the  definition  of  information  applicable  to  any  product.  The  Integrated 
Resources  establish  the  explicit  data  architecture.  APs  define  information 
applicable  to  specific  product  data  applications  using  the  Integrated  Resources. 
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4.2.1  Integrated  Resources 

The  Integrated  Resources  of  STEP  are  specified  as  constructs  within  a logically 
defined  organization  that  satisfies  the  STEP  resource  architecture  [11].  The 
constructs  are  developed  with  an  emphasis  on  product  data  subject  area 
requirements  (Fig.  1).  Product  data  application  needs  are  considered  primarily  in 
a general  sense  (i.e.,  constructs  are  expected  to  be  useful  for  a variety  of  specific 
product  data  applications). 


Integrated  Resources  contain  both  generic  resources  and  application  resources. 
Generic  resources  are  constructs  applicable  to  multiple  product  types,  application 
domains,  and  life  cycle  phases  that  are  free  of  application  context  constraints. 
Application  resources  add  to  and  specialize  generic  resource  constructs  to 
establish  specific  relationships  and  constraints  which  are  applicable  to  one  or 
more  applications  in  a common  context.  A common  context  may  involve 
multiple  product  types,  application  domains,  or  life  cycle  phases.  Generic  and 
application  resources  are  further  categorized  for  ease  of  comprehension. 
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Generic  Resources 


Product  Description  Resources:  Resources  that  specify  the  conceptual  structure  of 
product  data  in  STEP.  The  product  description  resources  contain  four  constructs 
which  provide  the  overall  logical  structure  of  the  STEP  Integrated  Resources. 
They  are  the  result  of  the  development  of  the  Generic  Product  Data  Model  [12]. 

Product  Definition  Context  describes  the  condition  under  which  product 
data  was  established  or  the  conditions  for  which  it  is  applicable.  This 
information  comprises  the  highest  level  of  conceptualization  in  STEP. 

Product  Definition  identifies  a product,  the  variance  in  its  descriptions, 
particular  context  dependent  product  definitions,  and  the  structure  and 
relationships  among  product  definitions.  This  information  is  the 
foundation  of  product  description  upon  which  other  resources  build. 

Product  Property  Definition  describes  the  characteristics  and  qualities  of  a 
product.  This  information  is  extendable  as  STEP  develop>s. 

Product  Property  Representation  describes  multiple  ways  in  which  the 
properties  of  a product  can  be  represented. 

Math  Support  Resources:  Resources  that  support  the  specification  of  other 
generic  resources  using  mathematical  definitions  (e.g.,  geometry  and  topology). 

Representation  Resources:  Resources  that  specify  the  representation  constructs 
associated  with  a product. 

Presentation  Resources:  Resources  that  specify  the  presentation  constructs 
associated  with  a product. 

Management  Resources:  Resources  that  specify  the  product  life  cycle 
management  constructs  associated  with  a product. 

Application  Resources 

Drafting  Resources:  Resources  that  specify  drawing  related  constructs  associated 
with  a product  in  the  context  of  drafting  common  to  multiple  applications. 

The  number  of  categories  of  Integrated  Resources  (generic  and  application)  is 
expected  to  increase  as  STEP  continues  to  develop.  The  STEP  project  expands  the 
scope  of  the  IRs  in  direct  response  to  the  development  needs  of  STEP  application 
protocols. 
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4.2.2  Application  Protocols 


The  primary  purpose  of  application  protocols  (APs)  is  to  provide  a basis  for 
sharing  information  within  a chosen  application  context  and  for  standard 
conformance  verification.  As  such,  it  includes  elements  that  (1)  state  explicitly 
the  information  requirements  of  a particular  application  domain,  and  (2)  specify 
the  meaning  of  shared  information  in  that  application  domain.^ 

Based  on  these  objectives,  STEP  application  protocols  include  five  elements  [13]. 

1.  Definitions  of  the  application  context,  scope,  and  functional  requirements 
which  are  recommended  to  include  an  application  activity  model  (AAM). 

2.  An  application  reference  model  (ARM)  that  describes  the  information 
requirements. 

3.  An  application  interpreted  model  (AIM)  that  specifies  the  interpretation  of 
the  integrated  resource  constructs  to  provide  constructs  for  the  required 
information  requirements. 

4.  Conformance  requirements  including  the  definition  of  test  purposes  that 
provide  the  basis  for  separately  documented  abstract  test  suites. 

5.  Usage  guidelines  that  provide  material  on  employing  the  application 
protocol  for  sharing  of  context  specific  information. 

The  application  protocols,  therefore,  have  two  classes  of  information  models: 
application  reference  models  and  application  interpreted  models.  Application 
reference  models  capture  the  information  requirements  of  the  identified 
application  domain  using  domain  specific  terminology,  data  structures,  and 
constraints. 

The  application  interpreted  models  adapt  appropriate  Integrated  Resources  for 
use  in  the  specific  application  context.  The  AIMs  employ  the  STEP  product  data 
structure  specified  within  the  Integrated  Resources.  Mappings  are  established 
from  the  ARMs  and  Integrated  Resources  to  the  AIMs  that  document  their 
derivation. 


2 Each  application  protocol  is  self-sufficient  for  the  communication  of  information  in  a given 
context.  This  does  not  mean  that  STEP  is  a collection  of  independent  and  unrelated  context 
specific  models.  Information  sharing  among  applications  using  different  application  protocols 
is  accommodated  through  the  use  of  a common  data  architecture  established  by  the  integrated 
resources  and  through  AP  integration  (see  4.2  Global  System  Architecture). 
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The  AIMS  collect  required  resource  constructs  and  adapt  the  semantics  of  the 
resources  as  appropriate  for  the  identified  application  context  (Fig.  2).  Since  an 
application  interpreted  model  is  neutral  to  all  applications  within  its  defined 
context,  it  is  conceptual  in  nature  with  regard  to  that  context. 


4.3  Specification  of  Context  Specific  Information 


The  specification  of  information  requires  adequate  consideration  of  both  product 
data  subject  area  and  product  data  application  requirements.  Standardized 
constructs  for  information  sharing  are  developed  in  STEP  from  both  of  these 
perspectives.  The  Integrated  Resources  define  data  constructs  emphasizing 
product  data  subject  areas.  The  application  protocols  define  the  semantics  of 
consensus  user  views  for  specific  application  contexts  (i.e.,  product  data 
application  requirements).  The  AIM  defines  the  specific  constructs  required  for 
the  sharing  of  meaningful  information  based  upon  both  sets  of  data 
requirements. 
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5 Information  System  Architectures 


Elements  of  the  STEP  information  architecture  can  be  related  to  the  classic  three 
schema  database  system  architecture  [14,15].  Figure  3 illustrates  this  architecture 
used  in  a centralized  database  design-  It  includes  external,  conceptual,  and 
internal  schemas  that  represent  the  points  of  view  of  user  applications,  a 
common  underlying  semantic  data  structure,  and  physical  data-storage  structures 
of  implementations.  The  architecture  also  includes  external  and  internal 
processors  that  manage  the  operations  of  a system.  The  architecture  optionally 
includes  a logical  schema  and  associated  processor  between  the  external  and 
internal  elements.  Logical  schemas  are  derived  from  the  conceptual  schema 
adapting  it  to  particular  implementation  approaches  (e.g.,  relational  or  object 
oriented  databases). 


Figure  3.  Centralized  Database  System 


DATABASE 


Information 

Base 


t Message 
1 (meaning) 


^ Information 
t Processor 


Conceptual 

Schema 


mapping 


External 

Schema 


Internal 

Schema 


External 

Processor 


Message 

(form) 


Internal 

Processor 


AdluL 

Henunt 


Internal 

Database 


■VIrtuit 

a«mtRt 


In  STEP,  the  Integrated  Resources  (generic  and  application)  and  the  application 
interpreted  models  are  conceptual  in  nature  [16].  They  represent  shared  neutral 
points  of  view  from  which  multiple  user  applications  and  implementations 
could  be  mapped.3 


STEP  does  not  currently  address  the  development  of  logical  schemas  [15]  that  adapt  the 
conceptual  schema  for  particular  implementation  types  (e.g.,  relational  or  object  oriented). 
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A high  degree  of  context  specificity  is  necessary  to  provide  data  constructs  with 
adequate  semantic  completeness  for  information  sharing  in  STEP  (Fig.  4).  The 
Integrated  Resources  are  not  adequately  specified  to  serve  as  the  conceptual 
schema  for  STEP  implementations.  The  context  of  each  resource  is  the  product 
data  subject  area  defined  by  its  scope.  The  Integrated  Resources  unify  these 
scopes.  The  Integrated  Resources  do  not  contain  the  context-specific  semantics 
that  establish  utility  (i.e.,  they  are  incomplete).  Application  protocols  are 
established  to  supply  the  specificity  required  for  meaningful  information  sharing 
for  product  data  applications  using  STEP. 

Each  application  protocol  contains  one  or  more  application  interpreted  model. 
Each  AIM  is  the  conceptual  schema  for  the  specified  application  context  and 
provides  a standardized  set  of  constructs  for  information  sharing.  AIMs  are 
designed  to  support  multiple  external  user  application  views  and 
implementations  within  the  complex  information  sharing  environment  in 
which  STEP  must  function.  Both  federated  and  global  system  architectures  are 
accommodated  by  the  STEP  development  approach. 
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5.1  Federated  System  Architecture 


A federated  database  system  architecture  involves  more  layers  than  the  classical 
three  schema  architecture.  A five  schema  architecture  has  been  proposed  [5] 
which  includes  local,  component,  import /export,  federated,  and  external 
schemas  (Fig.  5). 


Figure  5.  Federated  Database  System 
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Local  Schema:  The  schema  of  a local  database  system  specified  in  a locally 
chosen  modelling  language  (e.g.,  SQL  for  a relational  database). 

Component  Schema:  A local  schema  in  a common  modelling  language 
(e.g.,  C++)  used  by  the  federated  system.  A component  schema  may  contain 
semantics  missing  in  the  local  schema  but  required  by  the  federated  system. 

Import/Export  Schema:  A subset  of  the  component  schema  that  contains 
information  used  to  control  access  to  an  autonomous  component  database. 
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Federated  Schema:  A conceptual  schema  that  supports  a group  of  users  or 
applications  performing  a related  set  of  activities.  It  may  include  distribution 
information  or  be  used  with  a distribution  schema. 

External  Schema:  Provides  a user  application  view. 

In  a federated  system  architecture,  STEP  application  protocols  provide  data 
specifications  relevant  at  the  external  and  federated  levels. 

An  ARM  represents  the  consensus  external  view  that  specifies  the  detailed 
information  requirements  of  an  application  protocol.  Few  users,  however,  have 
requirements  to  manage  all  data  elements  in  the  ARM.  Additional  external 
views  are  expected  to  provide  data  in  forms  appropriate  for  particular  users  and 
activities,  emphasizing  functionality  within  the  application  context. 

An  AIM  contains  standardized  constructs  that  are  the  basis  for  the  sharing  of 
information  among  a group  of  users  or  applications  performing-a  related  set  of 
activities.  To  conform  to  an  application  protocol  means  a system  must  be  capable 
of  information  sharing  based  on  entities  and  attributes  within  an  AIM  of  that 
AP.  Functionally,  an  AIM  is  a federated  conceptual  schema.  The  constructing 
processor  provides  data  access  to  multiple  component  databases. 

In  a product  data  exchange  environment,  processors  that  can  translate  local 
databases  into  a STEP  exchange  format  require  the  functional  equivalent  of 
component  and  import/export  schemas.  The  component  schema  allows  for 
retrieval  of  data  from  the  local  database  providing  data  elements  suitable  for 
STEP  exchange.  The  import/ export  schema  controls  which  federation  users 
have  access  to  specific  information. 

Finally,  it  should  be  noted  that  in  those  situations  where  the  local  database  is  a 
computer-aided  system  (e.g.,  computer-aided  design,  CAD)  additional  local 
external  views  are  typically  used  as  the  basis  for  local  user  interfaces. 

The  use  of  a federated  information  system  architecture  is  a viable  solution  to 
the  problem  of  sharing  information  in  a heterogeneous,  distributed,  and 
autonomous  environment.  It  is  particularly  well  suited  to  capturing  context 
specific  information  requirements  within  conceptual  schemas  that  are  derived 
from  the  conunon  set  of  STEP  Integrated  Resources.  The  Integrated  Resources 
provide  a single  architecture  for  product  data.  Another  approach  to  information 
sharing  in  this  complex  environment  is  the  global  system  architecture. 
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5.2  Global  System  Architecture 


A global  system  architecture  has  a single  conceptual  schema.  In  STEP,  the 
development  of  a global  schema  relies  upon  application  protocol  integration  [18]. 

The  identification  of  common  constructs  across  multiple  ATMs  is  a critical  aspect. 
When  common  functionality  is  identified  in  multiple  application  contexts  (i.e., 
different  APs),  a common  data  specification  is  used.  Sharing  common  data 
specifications  among  APs  enables  information  sharing. 

AP  integration  identifies  common  constructs  within  AIMs  and  specifies  them  as 
Application  Interpreted  Constructs  (AICs).  AICs  are  placed  in  an  AIC  library  for 
common  use  during  STEP  development.  The  AIC  library,  therefore,  contains 
common  data  specifications  for  AIM  development.  AICs  are  copied  to  the  AIM 
in  each  of  the  APs  sharing  the  construct.  AICs  differ  from  the  Integrated 
Resources  in  that: 

1)  an  AIC  is  an  interpretation  of  the  Integrated  Resources  that  has  a specific 
scope  and  context  based  on  product  data  application  requirements  and  is 
thus  semantically  complete  for  the  sharing  of  information;  and 

2)  the  use  of  AICs  involves  exact  copies  without  any  additional 
interpretation  to  ensure  interoperability  among  applications  using 
different  APs  that  desire  the  ability  to  share  information. 

AIMS  are  developed  using  AICs  where  possible.  Only  upon  determining  that  an 
AIC  is  not  available  or  cannot  be  created  by  using  an  AP  specific  construct  from 
an  existing  AP  with  common  scope  are  the  STEP  Integrated  Resources  used  in 
the  development  of  an  AIM. 

The  AIC  library  approach  to  AP  integration  provides  the  ability  to  discover  over 
time  which  applications  actually  have  requirements  for  information  sharing.  It 
provides  appropriate  interoperability  for  computer  systems  using  STEP.  It 
provides  for  the  explicit  definition  of  shared  AICs  among  such  systems.  It 
provides  a basis  for  testing  and  conformance  as  part  of  the  methodology.  The 
approach  is  responsive  to  the  complex  information  requirements  of  STEP  thus 
ensuring  that  shared  information  is  of  value. 

STEP  Global  Schema 


The  global  schema  of  STEP  is  the  combination  of  the  constructs  of  the  AIC  library 
and  those  limited  constructs  unique  to  application  protocols.  The  AIMs  of 
application  protocols  are  subsets  of  this  global  schema. 
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The  development  of  the  STEP  global  schema  is  an  integral  part  of  the  evolution 
of  the  standard.  Its  foundation  is  the  product  data  structure  developed  through 
the  integration  of  resource  constructs.  Information  sharing  capabilities  are 
ensured  by  the  application  interpretation  of  the  Integrated  Resources  to  satisfy 
explicitly  stated  product  data  application  requirements.  Interoperability  is  based 
on  the  actual  needs  of  international  industry  and  commerce.  It  is  achieved 
through  application  protocol  integration  as  an  inherent  aspect  of  application 
interpretation. 

The  STEP  development  process  provides  an  implicit  shared  global  view 
containing  data  constructs  developed  specifically  for  the  sharing  of  information 
in  the  complex  information  system  environment  in  which  STEP  must  operate. 
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6 Summary 


STEP  Integrated  Resources  and  application  protocols  contain  the  standardized 
constructs  that  facilitate  information  sharing  among  computer  systems.  The 
Integrated  Resources  accommodate  product  data  applications  through  ongoing 
consideration  of  product  data  subject  area  requirements  within  the  scope  of 
STEP.  Application  protocols  ensure  the  precision  and  utility  of  information 
sharing  for  specific  product  data  application  contexts  while  maintaining  the 
flexibility  required  as  data  usage  undergoes  change  due  to  process  improvement. 

Viewed  from  within  the  STEP  development  process,  STEP  contains  standardized 
constructs  within  the  Integrated  Resources,  AIMs,  and  AIC  library  (Fig.  6). 

Viewed  from  outside  the  development  process,  however,  STEP  is  a set  of 
integrated  application  protocols.  These  APs  share  application  interpreted 
constructs  in  a mofular  fashion.  Very  limited  unique  semantics  are  used. 


Each  application  protocol  provides  an  application  interpreted  model.  Each  AIM 
is  a portion  of  the  STEP  standard  and  the  conceptual  schema  for  the  defined 
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application  context.  Each  AIM  is  designed  to  support  multiple  external  user 
views  and  implementations  within  the  complex  and  expansive  scope  of  STEP. 

The  use  of  standardized  AIMs  that  share  AICs  is  analogous  to  a combined 
federated  and  global  approach  to  multidatabase  integration  in  a heterogeneous, 
distributed,  and  autonomous  environment.  Advantages  to  such  a combined 
approach  in  STEP  include: 

• interoperability  in  sequential  file,  centralized 
database,  and  multidatabase  environments 

• responsiveness  to  user  needs 

• effectiveness  with  respect  to  attaining 
consensus  within  identified  contexts 

• flexibility  with  respect  to  change 

• maintainability  of  the  specification 

• accommodation  of  legacy  systems 


As  a standard  to  facilitate  information  sharing,  STEP  provides  standardized 
AIMS  that  serve  as  necessary  control  mechanisms  for  the  unambiguous  sharing 
of  information  in  specified  product  data  application  contexts.  The  STEP  methods 
and  architectures  used  to  develop  the  AIMs  support  both  precision  of  the 
information  shared  and  flexible  information  sharing  among  product  data 
applications. 

STEP  facilitates  the  establishment  of  an  information  sharing  capability  for 
applications  involving  all  product  types  over  the  entire  life  cycle  of  products.  It 
satisfies  the  product  information  needs  of  international  industry  and  commerce 
by  providing  the  ability  to  share  information  precisely  and  unambiguously,  the 
ability  to  share  information  among  specific  applications,  and  the  ability  to  change 
as  business  processes,  and  the  automated  use  of  information  are  improved. 
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